src/lib/nim.test.ts (2)

204-223: ⚠️ Potential issue | 🟡 Minor

Keep the container contract under test in these nimStatusByName() cases.

These assertions now only check running/healthy, but src/lib/nim.ts still returns container on every path and bin/nemoclaw.js prints nimStat.container. Dropping that field from the expectations makes a CLI-visible regression invisible to this suite.

🧪 Suggested assertion updates

-          expect(st).toMatchObject({ running: true, healthy: true });
+          expect(st).toMatchObject({
+            running: true,
+            healthy: true,
+            container: "foo",
+            state: "running",
+          });
...
-        expect(st).toMatchObject({ running: true, healthy: true });
+        expect(st).toMatchObject({
+          running: true,
+          healthy: true,
+          container: "foo",
+          state: "running",
+        });
...
-        expect(st).toMatchObject({ running: false, healthy: false, state: "exited" });
+        expect(st).toMatchObject({
+          running: false,
+          healthy: false,
+          container: "foo",
+          state: "exited",
+        });

Also applies to: 226-241, 243-253

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/nim.test.ts` around lines 204 - 223, The tests for nimStatusByName
drop asserting the returned container shape which causes regressions because
src/lib/nim.ts still returns a container field and bin/nemoclaw.js prints
nimStat.container; update the expectations in the test cases that call
nimModule.nimStatusByName("foo") (including the blocks at the shown range and
the other noted ranges 226-241 and 243-253) to assert the container value/shape
is present (e.g., include container in the object passed to toMatchObject or add
an explicit expect(nimStat.container).toEqual(...) or toBeDefined()) so the
suite verifies the container contract alongside running/healthy.

---

95-118: ⚠️ Potential issue | 🟡 Minor

Please add a mocked test for the primary NVIDIA detection path too.

These new cases only exercise the unified-memory fallback. The regular nvidia-smi --query-gpu=memory.total branch in src/lib/nim.ts is still effectively covered by the live-host nvidia type is nimCapable check above, which will fail on low-VRAM NVIDIA machines. The Xavier case here already shows type: "nvidia" does not imply nimCapable: true, so the suite is still hardware-dependent.

Also applies to: 120-143, 145-166

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/nim.test.ts` around lines 95 - 118, Add a mocked unit test that
exercises the primary NVIDIA detection branch (the path that parses `nvidia-smi
--query-gpu=memory.total`) by using loadNimWithMockedRunner and a runCapture
mock that returns a non-empty value when cmd.includes("memory.total") (e.g.
"16384"), returns "NVIDIA <model>" for query-gpu=name, and returns an
appropriate free -m value; call detectGpu() and assert the resulting object has
type "nvidia", unifiedMemory: false, nimCapable set according to the parsed
memory, and perGpuMB/totalMemoryMB matching the mocked values. Ensure you add
the same style of mocked tests for the other cases noted (lines around 120-143
and 145-166) so the nvidia-smi primary branch is covered deterministically
without relying on host hardware.